1. Field of the Invention
The present invention, in general, is relates various messaging applications developed over Session Initiation Protocol (SIP) like Instant Messaging (IM), Push to talk over Cellular (PoC), Converged IP Messaging (CPM). Particularly this invention relates to those applications where messages arriving for a User are stored temporarily or persistently (e.g., because user is not registered currently, user does not wish to receive the message immediately) by the Service Provider. More particularly the present invention relates to a system and method for deferred message reminders and expiry extension.
2. Description of the Related Art
Currently, when a User is not registered to the Service there can be messages arriving from other Users but cannot be delivered to the recipient User immediately because of reasons like User is not registered to the service. Such messages are temporarily stored by the Server for later delivery and called as Deferred Messages. When the User registers to the Service, depending on User Preferences, User may either get pushed Deferred Messages directly or receive Notification about the arrival of Deferred Message. In the latter case, User may either retrieve the Deferred Messages immediately or can defer it for later retrieval. Depending on the message originator's preferences or the Service Provider policy, Deferred Messages that are temporarily stored on the Server may be deleted by the Server after some period if not retrieved before an expiry time the originator or the Service Provider associated with the Deferred Message. Also the messages may be deleted by the Server without delivering to the User if the Deferred Messages are expired before the User retrieves them. Hence User may lose some Deferred Messages without being delivered to him.
The mechanism in current art can be better explained with FIG. 1 and FIG. 2.
FIG. 1 depicts OMA (Open Mobile Alliance) developed solution for Deferred Messages where meta data is stored in Application Server (AS) itself along with the Deferred Messages.                1. User not registered to the network or User does not wish to receive messages immediately etc.        2. Message arrives from other Users.        3. When a message arrives at the Application Server to be delivered for an User, it checks if the message has to be temporarily stored because of reasons like User not registered to the network or User does not wish to receive immediately etc. If the message is not for immediate delivery, Application Server creates the meta data for the deferred message and stores in the temporary storage along with the actual message which is to be delivered at a later stage.        4. Assuming User has registered to the network now or is willing to retrieving any deferred message.        5. User Client subscribes to the metadata document to know if there are any messages waiting for retrieval. SIP SUBSCRIBE request is sent to Application Server (where the meta data is stored) to know the messages waiting for retrieval.        6. Application Server acknowledges the receipt of subscribe request.        7. Server then generates single notification containing the meta data of all the messages waiting for retrieval. Client is notified using SIP NOTIFY method. For each Deferred Message, notification contains the meta data in the format as mentioned below:        
The <history> element in OMA developed IM Application comprises of:<size> element representing the size of the stored content;<expiry> element representing the date at which the message expires;<subject> element representing the Subject header field of the SIP request;<pager> element containing:<time-stamp> element representing the creation time of the message;<from> element taken from the “From” header field of the SIP request;<to> element taken from the “To” header field of the SIP request alwaysfilled if the message is sent to one IM user;“date” attribute representing the date when the message was sent;“history-reference” attribute representing the complete path and uniqueidentifier of the actual content of the message;                8. Client acknowledges the receipt of the notification.        
FIG. 2 depicts OMA developed solution for Deferred Messages where meta data is stored in XML Document Management Server (XDMS) itself along with the Deferred Messages.                1. User not registered to the network or User does not wish to receive messages immediately etc.        2. Message arrives from other Users.        3. When a message arrives at the Application Server to be delivered for an User, it checks if the message has to be temporarily stored because of reasons like User not registered to the network or User does not wish to receive immediately etc. If the message is not for immediate delivery, Application Server creates the meta data for the deferred message.        4. Application Server generated meta data is stored in another entity like XDMS.-XML Configuration Access Protocol (XCAP) PUT method is used to write the meta data information in the document that is present in XDMS. XDMS then updates the meta data into a document.        5. XDMS acknowledges the receipt of XCAP PUT request.        6. Assuming User has registered to the network now or is willing to retrieving any deferred message.        7. User Client subscribes to the metadata document to know if there are any messages waiting for retrieval. SIP SUBSCRIBE request is sent to XDMS (where the meta data is stored) used to know the messages waiting for retrieval.        8. XDMS acknowledges the receipt of subscribe request.        9. XDMS then generates single notification containing the meta data of all the messages waiting for retrieval. Client is notified using SIP NOTIFY method. For each Deferred Message, notification contains the meta data in the format as explained in FIG. 1 Step-7.        10. Client acknowledges the receipt of the notification.        